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ABSTRACT 



A program conversion apparatus that converts a source 
program to an executable program, the source program 
including a first descriptor indicating dynamic memory 
allocation. The program conversion apparatus includes a 
specifying unit and a generating unit. The specifying unit 
specifies in the source program a reference descriptor that is 
last to be executed from reference descriptors indicating 
references to memory allocated by the first descriptor. The 
generating unit generates an instruction for freeing the 
allocated memory at a position in the executable program 
immediately following an instruction that corresponds to the 
specified reference descriptor. 
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Fig. 12 
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Fig. 14 



(a) PRIOR TO LOCALIZING 
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(1) 
(2) 
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c = a + 1 ; 
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(b) AFTER LOCALIZING 

void sample (int k) 
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// ALLOCATE MEMORY 
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// USE CODE 
// USE CODE 



// ALLOCATE LOCAL VARIABLE 



(12) c= a + 1 ; 
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Fig. 15 

(a) PRIOR TO CONTINUOUS PROCESSING 
void sample (int k) 
int *b ; 



for (i=0; i<200; 
(1) new int a ; 



// ALLOCATE MEMORY 



(2) a = (calc(i)+calc(i + l))/2 ; fJ US£ CQDE 



(3) b= &a; 



// USE CODE 



(4) other_function(b) ; // USE CODE 



} 



(b) AFTER CONTINUOUS PROCESSING 
void sample (int k) 
int *b ; 



(11) new int a = [200] ; 
for (i=0; i<200; i++) 

(12) a[i] = (calc(i)+calc(i + l))/2 ; // USE CODE 

(13) b= &a[i] ; // USE CODE 

(14) otherjunction(b) ; // USE CODE 
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Fig. 16 

(a) PRIOR TO CONTINUOUS LOCALIZING 
void sample(int k) 

int *b ; 

for (i=6; i<200; i++) 

(1) new int a ; // ALLOCATE MEMORY 

(2) a = (b+calc(i ))/2 ; // USE CODE 

(3) printvalue(a) ; // USE CODE 

(4) b = &a ; // USE CODE 
} " 

} 

(b) AFTER CONTINUOUS LOCALIZING 
void sample(int k) 

fl 1) int a[200] ; // ALLOCATE MEMORY IN BULK 

int *b ; 

for (i=0; i<200; i++) 

(12) a[i] = (b+calc(i ))/2 ; // USE CODE 

(13) printvalue(a[i]) ; // USE CODE 

(14) b=&a[i]; //USE CODE 



} 
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Fig. 17 

(a) PRIORTO SHARE PROCESSING 

voidsamde$ntk) 
{ 

for(i=0;i<200;i++) 
{ 

(1) newinta ; // ALLOCATE MEMORY 

(2) a=(calc0+ca!c(+l))/2; // USE CODE 

(3) printvalue(a); //USE CODE 
} ' 

} 

(b) AFTERSHARE PROCESSING 
void sample (ill k) 

(11) inta; // ALLOCATE JUST ONE LOCAL VARIABLE 

for (i=0; i<200; i-t-f-) 
{ 

(12) a=(calcG)+calc(+l))/2; //USE CODE 

(13) printvalue(a); //USE CODE 
} ' 

} 
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PROGRAM CONVERSION APPARATUS FOR IB. Here, a source program is first converted into Java 

ELIMINATING UNNECESSARY bytecode by the compiler (linker). Then an interpreter trans- 

INDICATTONS OF DYNAMIC MEMORY lates the Java bytecode into execution-format code and 

ALLOCATION FROM A SOURCE PROGRAM executes it. In Java, memory is allocated by the object 

AND GENERATING AN EXECUTABLE 5 generating operator new and freed by the interpreter. 

PROGRAM Th e following is a more detailed explanation of the way 

that memory is freed in these memory management meth- 

This application is based on an application No. oc k- 

11-137762 filed in Japan, the content of which is hereby ^ manual memory management, memory is freed by an 

incorporated by reference. io explicit program instruction, so that responsibility for free- 
ing memory rests with the program, and the execution thread 

BACKGROUND OF THE INVENTION does not determine whether data in the heap area is in use or 

1. Field of the Invention not - 

The invention relates to a program conversion technique, . However, in a program written in C++ or similar, a free 

and in particular to a technique that uses a compiler to assist « instruction may be erroneously omitted from the program by 

in the management of dynamic memory allocation by the thc P™g™er, thereby preventing the recycling of 

execution thread memory which is no longer in use and should therefore be 

2 Related Art freed. As a result, the amount of available memory may be 

insufficient to execute the program, and the original program 

Most conventional programming languages use severa ^ win haye difficmt m specifying ^ cause of suc h lack of 

types of variables. These may be classified into global memorVt Conversely, suppose that memory which is still 

variables, which are allocated memory throughout execution bd ^ b ^ m fc freed b mistake (alsQ 

of an entire program, ocal variables which are allocated u a ature foe). If the data that was allocated to this 

memory only when a local section of a program such as m ^ ^ ^ b ^ ^ tfae resulling 

inside a particular function, is executed, and dynamic program b ng is extremely difficult to trace, 

variables, which are allocated memory dynamically using a R . ^ ^ indkate appropriate times for freeing 

code within a program. Examples of codes for allocating memory whcn using a maQua l memory management method 

memory dynamically to variables are the hbrary function such as (1) is on occasion m extremely difficult task . ^ 

maUoc used in C programming language and the object ^pancy between memory holding data that is 

generating operator new used in Java™. 3Q nQ longer m use ^ memory that ^ actually focd by the 

Memory allocated to a local variable is certain to be freed prograin mea ns that there is always a risk of generating the 

once execution of a local program section, such as calling a above-described inefficiencies. 

function, has been completed, but it is more difficult to In the ailt omatic memory management method (2), 
determine the point in the program at which a dynamic however, only the allocation of memory is indicated in the 
variable will no longer be required. The following is an 35 pr0 g ram> ^6 the freeing of memory is left wholly to the 
explanation of the use of dynamic variables. execution thread (through the automatic memory manage- 
When dynamic variables are used by a computer, the size me nt of the interpreter). This avoids the risks posed by the 
of an area used for dynamic memory allocation of variables manual memory management method (1), thereby allowing 
(the heap area) is limited. This means that some kind of the proper use of data which has been dynamically allocated 
mechanism is required to free the part of the heap area 40 memory. 

allocated to variables that are no longer in use, thereby i n a j ava interpreter (execution thread) used in the auto- 
allowing it to be used by new variables. matic memory management method (2), dynamic memory 
The methods used to free the part of the heap area management can be smoothly performed using garbage 
occupied by data (variables) that are no longer in use, can be collection. Garbage collection consists of 'identification' 
roughly divided into two, depending on which type of 45 processing for determining whether data stored in the heap 
programming language is used. area is in use (alive), or not in use (garbage), and 'recycling' 

1. The programmer explicitly writes an instruction for processing for collecting into one all memory allocated to 
freeing memory in the source program, in the same way data which has been determined to be no longer in use. 

as when memory is allocated. This method forms part Object-orientated languages have become a focus of 

of what is known as manual memory management. 50 attention in recent years for reasons such as their high degree 

2. A program execution thread determines whether data of program re-use. Most object-orientated languages allo- 
allocated memory in the heap area is still in use or not, cate memory in the heap area to objects, so that the execu- 
and frees memory allocated to data that is no longer in tion capability of an application written in object-orientated 
use. Tbis method forms part of what is known as language is frequently determined by the success rate of 
automatic memory management. 55 memory management performed by execution threads. 

FIG. 1 illustrates the generation of execution-format code Both C++ and Java are object-orientated languages, but 

in C, C++ and Java. since Java uses automatic memory management, freeing 

As shown in FIG. 1A, programming languages such as C dynamically-generated objects is left entirely to a garbage 

and C++ use a manual memory management method ((1) collector (the device performing garbage collection), 

above), in which a source program is converted into machine 60 The following is one example of a program written in 

code by a compiler (linker) and the machine code is Java, 

executed direcdy as execution format code. In C, memory is for (i=0;i<1000;i++){ 

allocated by the library function malloc and freed by a g.setcolor(new color(0,0,i))// set a color for object g 

hbrary function free, while in C++ memory is allocated by g.line(0,l,999,i) } // draw a line under object g 

an operator new and freed by an operator delete. 65 In this program, the operator new is used in a for loop to 

Programming languages such as Java, however, use auto- dynamically generate an object in a class color. However, a 

matic memory management ((2) above), as shown in FIG. color class object is only used for a short period due to the 
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fact that a different color is set on each loop repetition, so (2) The above change of functions cannot be applied if a 
that the color class object is likely to become garbage free instruction is omitted from the program due to a 
immediately following the execution of g.sctcolor(new color programmer error (when manual memory management 
(0,0,0) for ea p n value of i- is used by a programming language such as C++) or if 
An instruction set for a Java virtual machine (a bytecode s the programming language is not equipped for indicat- 
execution thread including an interpreter) conforming to the mg mem0 ry freeing explicitly in the program (when 
specifications stipulated by Sun Microsystems Inc does not automatic memory management is used by a program- 
include an instruction for freeing heap area. In other words, m - language such ^ Java y ^ a rcsult> tnerc ca nnot 
freeing of memory in the part of the heap area that is be ^ to be sufficient reductioil in me amount of 
allocated to objects is Performed entirely by the garbage d ^ management performed by the execu- 
collector in Java, so that the garbage collector is responsible , , & r . 
for deleting all of the 1000 objects generated inside the for on rea . 

loop in the above program. SUMMARY OF THE INVENTION 

However, it is generally well-known that execution of 
garbage collection by the garbage collector expends a great In ™ w of the above problems, the object of the present 
deal of time (processing cost). According to page 45 of the 15 invention is to provide a program conversion apparatus 
July 1998 issue of the monthly magazine Java World, capable of reducing the amount of dynamic storage man- 
published by IDG Communications, roughly 20% of the agement placed on the execution thread when a program is 
execution time in a standard Java application is occupied by executed. 

garbage collection. Furthermore, applications including frc- a first program conversion apparatus relating to the 

quent repetition of allocation (reserving) and freeing 20 invention converts a source program to an executable 

(deallocation) of memory, of which generation of objects program, the source program including a first descriptor 

inside a loop is a representative example, devote a large indicating dynamic memory allocation, 

proportion of execution time to garbage collection. This ™ . . . . . , . f . 

r , r . . * ^ t_i r *u This program conversion apparatus includes a specifying 

reduces the amount of time available for executing the , r * . iL r 

t- *■ ■* «r it. ? * unit for specifying in the source program a reference 

application itself . Thus, even if optimizing program code has 25 j • t f u * • i * * u . j c c a 

* r , , ** - c i • « descriptor that is last to be executed from reference descrip- 

speeded up its execution, the effect of such improvements . • j- ^ c * n * j u *u c + 

11 h r t H s mcucatm g references to memory allocated by the first 

f 1 ' * . * . - iL . ^ • descriptor; and a generating unit for generating an instruc- 

A further disadvantage of garbage collection is that it is c d - £ « * j * * *u 

, , 4 . A ° 1 n . i . c .-I tion for freeing the allocated memory at a position m the 

impossible to estimate how long it will take to perform until t ^ . . . r « i • * 

. t ^ i A •. -tl • *i_ * ,l * i c * executable program immediately following an instruction 

it has been completed. This means that the risk of suspension 30 4 r \ r\ iL c A T r j 

„ r , . j. j i- that corresponds to the specified reference descriptor, 

of program execution or a dramatic drop in performance , , . . T . „ 

during garbage collection can never be entirely dismissed. ™™ «? executable program written m Java or a similar 

This kind of risk may prove to be a fatal flaw when writing programming language is executed this construction pre- 

applications that demand an interactive processing thread ven , ts ™ mo W lifetimes from being unnecessarily 

and real-time implementation. 35 P rolon S ed > mereb y reducmg the amount of dynamic 

Since the dynamic memory management performed by memor y management performed by the execution thread. 

Java execution threads includes garbage collection, as A second program conversion apparatus relating to the 

described above, Java is said to be unsuitable for writing invention converts a source program to an executable 

programs which demand real-time implementation. program, the source program including a first descriptor 

However, it may be possible to overcome such problems by 40 indicating dynamic memory allocation, and a second 

reducing some of the load placed on the execution thread by descriptor indicating memory allocation only when instruc- 

dynamic memory management (in other words by using tons are executed within a specified block, 

some kind of mechanism to change the Java bytecode when This program conversion apparatus includes a specifying 

compiling from source code into Java bytecode). unit for specifying a lifetime of allocated memory by 

The following techniques disclosed in Japanese Laid- 45 referring to positions in the source program of (1) the first 

Open Patent 8-272621 and Japanese Laid-Open Patent descriptor and (2) reference descriptors indicating refer- 

9-330232 both use a compiler to assist in dynamic memory ences to memory allocated by the first descriptor; a deter- 

management. mining unit for determining whether the specified lifetime is 

Japanese Laid-Open Patent 8-272621 discloses a tech- confined within the specified block; and a generating unit for 

nique for analyzing memory lifetimes, in which the malloc 50 generating an instruction in an executable program when the 

and free functions used in a source program for dynamically specified lifetime is determined to be confined within the 

allocating and freeing memory in the heap area are changed specified block, so that memory indicated as being allocated 

to an alloca function for allocating and freeing dynamic by the first descriptor in the source program is indicated as 

memory inside a function stack at a higher processing speed. being allocated by the second descriptor. 

Japanese Laid-Open Patent 9-330232 discloses a tech- 55 When an executable program written in Java or a similar 

nique for analyzing hfetimes in a dynamically allocated programming language is executed, this construction pre- 

memory, and changing the source program so that memory vents memory lifetimes from being unnecessarily 

areas with lifetimes which do not overlap are grouped prolonged, thereby reducing the amount of dynamic 

together, and memory in each group is shared. This reduces memory management performed by the execution thread, 

the need to call library functions for dynamically allocating eo A third program conversion apparatus relating to the 

and freeing memory. invention converts a source program to an executable 

However, both of these techniques share the following program, the source program including a first descriptor 

weaknesses: indicating dynamic memory allocation for a specified object, 

(1) Since a lifetime of an allocated memory area is a second descriptor indicating (1) repetition of instructions 

assumed to continue until a free instruction is issued by 65 within a specified block and (2) a number of repetitions, and 

the program, lifetimes are still likely to be unnecessar- a third descriptor indicating continuous dynamic memory 

ily prolonged. allocation for a specified plurality of objects. 
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This program conversion apparatus includes a specifying The program conversion apparatus includes a specifying 

unit for specifying a position of the first descriptor in a unit for specifying a lifetime of allocated memory, by 

source program; a determining unit for determining whether referring to positions in the source program of (1) the first 

the specified position of the first descriptor is within the descriptor and (2) reference descriptors indicating refer- 

spccified block; a detecting unit for detecting the number of 5 ences to memory allocated by the first descriptor; a deter- 

repetitions shown by the second descriptor corresponding to mining unit for determining whether the specified lifetime 

the specified block; and a generating unit for generating an lasts for one execution duration of the specified small block; 

instruction in an executable program when the specified ^ a geQeratmg ^ for generating an instruction for the 

position of ( the first descriptor is detennined to be withm the executable program ^ ^ specified lifetime is deter- 

specifiedbbck so thai t memory, determined by repeating Uie 1Q mined tQ ^ for less than Qne cxccution of ^ 

memory allocaUon indicated by the first descriptor for the ed ^ ^ ^ m ^ 

number of repetitions shown by the second debtor, is ^ fot ^ ^ ^ m * 

indicated as being allocated by the third descriptor the third as ^ ^ descfi t ±t third 

descriptor being positioned outside the specified block. descriptor being positioned within the specified large block 

When an executable program written in a programming J5 but outsMe ^ small blocli , 

language such as Java. C or C++ is executed, this construe- , , , _ . „ 

tion prevents dynamic memory from being allocated each ^ ™ executable program written in Java or a similar 

time a program block is repeated, thereby reducing the Programming language is executed, this construction pre- 

amount of dynamic memory management performed by the vents . necessary *Y**™ memor y allocation, thereby 

execution thread. Furthermore, the memory for each block „ Cueing the amount of dynamic memory management 

repetition is allocated continuously, enabling the recycling 20 P«fonncd by the execution thread, 

performed in dynamic memory management to be per- BRIEF DESCRIPTION OF THE DRAWINGS 
formed effectively. 

A fourth program conversion apparatus relating to the ^se and other objects, advantages and features of the 

invention converts a source program to an executable ^ invention will become apparent from the following descrip- 

program, the source program including a first descriptor ^on thereof taken in conjunction with the accompanying 

indicating dynamic memory allocation for a specified object, drawings which illustrate a specific embodiment of the 

a second descriptor indicating (1) repetition of instructions invention. In the drawings: 

within a specified small block, and (2) a number of FIG. 1 shows the generation of execution-format code in 

repetitions, and a third descriptor indicating continuous 30 C, C++ and Java; 

memory allocation for a specified plurality of objects only piG. 2 is a block diagram showing the overall construe- 
when instructions are executed within a specified large block Hon of a program conversion apparatus 100 in a first 
that includes the specified small block. embodiment of the invention; 

This program conversion apparatus includes a specifying FIG. 3 is a flowchart showing an outline of processing 

unit for specifying a lifetime of allocated memory, by 35 per f orme d by the program conversion apparatus 100; 

referring to positions in the source program of (i) the first FJG 4 ^ a is a flowchart ^ a reference ^ 

descriptor and (u) reference descriptors indicating refer- j . ^ . ? - 

y v ' . . j detection process in S13 of FIG. 3; 

ences to memory allocated by the first descriptor; a deter- r 

mining unit for determining whether the specified lifetime is FIG - 5 * a flowchart showing a process for calling a 

confined within the specified large block and also whether 40 ^routine seek_use_and 13 addresssubst (a) m S132 of 

the position of the first descriptor is within the specified FIG - 

small block; a detecting unit for detecting the number of FIG. 6 shows an example of a first program illustrating 

repetitions shown by the second descriptor corresponding to processing performed by a memory reference code detector 

the specified small block; and a generating unit for gener- I 03 a memory lifetime analyzer 104; 

ating an instruction in the executable program when (a) the 45 FIG. 7 shows an example of a second program illustrating 

specified lifetime is determined to be confined within the processing performed by the memory reference code detec- 

specified large block and (b) the position of the first descrip- tor 103 and the memory lifetime analyzer 104; 

tor is determined to be within the specified small block, so FIG. 8 illustrates processing performed by a memory free 

that memory, determined by repeating the memory alloca- code generating unit 105 on the program shown in FIG, 7; 

tion indicated by the first descriptor for the number of 50 FIG. 9 illustrates processing performed by a memory free 

repetitions shown by the second descriptor, is indicated as code deleting unit 110 on the program shown in FIG. 8; 

being allocated by the third descriptor, the third descriptor piG 10 fe a flowchart ^ detail localize ess _ 

being positioned within the specified large block but outside ^ rformed b a m localizing code generating unit 

the specified small block. m . fl §23 of mQ 3; 

When an executable program written in Java .or a similar 55 Ha n fa a flowcnart showi in detail mntinaawi 

programming language is executed, this construction pre- ^ performe d by a memory continuous code gener- 

vents unnecessary dynamic memory allocation, thereby * J**^ {q s2Q of nG - 

reducing the amount of dynamic memory management ~~ ^ . n , . , 

performed by the execution thread. , ™i. 12 15 a flowcha ? sba ^ m deUul contauous 

A t localizing processing performed by a memory continuous 

A fifth program conversion apparatus relating to the 60 , t . . . crr^ \ 

, * 4 ui localizing umt 113 in S18 of FIG. 3; 

invention converts a source program to an executable * . 

program, the source program including a first descriptor ™ G ^ f a flowchart showing m detail share processing 
indicating dynamic memory allocation, a second descriptor performed by a memory share code generating unit 114; 
indicating repetition of instructions within a specified small FIG. 14 shows program changes performed by the local- 
block, and a third descriptor indicating memory allocation 65 iz i n g processing; 

only when instructions are executed within a specified large FIG. 15 shows program changes performed by the con- 
block that includes the specified small block tinuous processing; 
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FIG. 16 shows program changes performed by the con- free code deleting unit HO deletes, from the intermediate 

tinuous localizing processing; format program 2, code written by the programmer for 

FIG. 17 shows program changes performed by the share dynamically freeing memory (free for C, delete for C++ and 

processing; and the like). 

r-f^-.o uiij- t.- « 5 The program conversion apparatus 100 also includes a 

FIG. 18 is a block diagram showing an overall construe- ^ m £ m * determining uni [5 0 6, a loop defining memory 

tion for a program conversion apparatus 150. determining unit 107, a loop defining local memory deter- 

DESCRIPTION OF THE PREFERRED mining unit 108, a loop memory determining unit 109, a 

EMBODIMENTS memory localizing code generating unit 111, a memory 

10 continuous code generating unit 112, a memory continuous 

The following is a description of a program conversion localizing code generating unit 113, and a memory share 

apparatus in an embodiment of the invention with reference code generating unit 114, all of which are connected to the 

to the drawings. invention. The local memory determining unit 106 deter- 

HG. 2 is a block diagram showing an overall construction mines whether a condition A, 'the memory lifetime is local' 
of a program conversion apparatus 100 in a first embodiment 15 is satisfied, based on a lifetime output from the memory 
of the invention. The program conversion apparatus 100 is lifetime analyzing unit 104. The loop defining memory 
actually constructed from hardware, including a CPU, determining unit 107 determines whether a condition B, 'the 
memory, an external memory device, an input device and a starting point for the memory lifetimeis inside a loop having 
display, but the drawing shows a construction for software a calculable number of repetitions* is satisfied. The loop 
that is executed by such hardware. In the following ^ defining local memory determining unit 108 determines 
explanation, the expression 'memory lifetime is local' whether the memory area concerned simultaneously satisfies 
means that memory is allocated for a variable, object or the both condition A and condition B. The loop memory deter- 
like, when execution of instructions inside a designated mining unit 109 determines whether a condition C, 'the 
block (program section) is started, and the allocated memory memory lifetime is confined to one loop repetition' is 
is freed when execution of the instructions inside the des- ^ satisfied. When the local memory determining unit 106 has 
ignated block has been completed. One example of such a determined that condition A is satisfied, the memory local- 
block is execution of a single function. In contrast, suppose izing code generating unit 111 changes the intermediate 
that an address for the dynamically allocated memory is format program 2 so that memory indicated as being 
itself specified as an argument when a function is called. In dynamically allocated is allocated as memory for a local 
this case, the address itself is likely to be referenced by the 30 variable. When the loop defining memory determining unit 
called function, so that the lifetime of the memory cannot be 107 has determined that condition B is satisfied, the memory 
limited to a single function, and thereby cannot be described continuous code generating unit 112 changes the interme- 
as a local lifetime. diate format program 2 so that memory indicated as being 

As shown in FIG. 2, the program conversion apparatus dynamically allocated to a loop having a plurality of rep- 
100 generates an executable program 3 from a source 35 etitions is allocated (dynamically and continuously) imme- 
program 1. The program conversion apparatus 100 includes, diately prior to the loop, as memory for a dynamic array 
in the same way as a conventional program conversion variable. When the loop defining local memory determining 
apparatus, a source program decoder 101, a memory alio- unit 108 has determined that conditions A and B are simul- 
cation code detector 102, a memory reference code detector taneously satisfied, the memory continuous localizing code 
103, a memory lifetime analyzing unit 104 and an execut- 40 generating unit 113 changes the intermediate format pro- 
able program generating unit 115. The source program gram 2 so that memory that is indicated as being dynami- 
decoder 101 converts the source program 1 to an interme- cally allocated to a loop having a plurality of repetitions is 
diate format program 2. The memory allocation code detec- allocated inside the block including the loop, as memory for 
tor 102 detects codes for dynamically allocating memory in a local array variable. When the loop memory determining 
the intermediate format program 2 (codes corresponding to 45 unit 109 has determined that condition C is satisfied, the 
malloc in C, and new in each of C++ and Java), and outputs memory share code generating unit 114 changes the inter- 
data from the intermediate format program 2 that specifies mediate format program 2 so that memory indicated as being 
these allocation codes. The memory reference code detector dynamically allocated is used so that it can be shared during 
103 detects codes referencing each allocated memory area processing of a repeated loop. 

based on the output from the memory allocation code 50 A program conversion apparatus 100 having the above 

detector 102, and outputs data in the intermediate format construction performs the following processing, as shown in 

program 2 that specifies these reference codes. The memory FIGS. 3 to 5, and FIGS. 10 to 13. 

lifetime analyzing unit 104 analyzes memory lifetimes based FIG. 3 is a flowchart showing an oudine of processing 

on the allocation codes detected by the memory allocation performed by the program conversion apparatus 100. FIG. 4 

code detector 102 and the reference codes detected by the 55 is a flowchart showing a reference code detecting process in 

memory reference code detector 103. The executable pro- S13 of FIG. 3. FIG. 5 is a flowchart showing a process for 

gram generating unit 115 converts the intermediate format calling a subroutine seek__use and_addresssubst (a) in 

program 2 into an executable program 3. S132 of FIG. 4. 

The program conversion apparatus 100 also includes a FIGS. 6 and 7 show example programs illustrating pro- 

memory free code generating unit 105 and a memory free 60 cessing performed by the memory reference code detector 

code deleting unit U0 that are particularly relevant to the 103 and the memory lifetime analyzing unit 104, FIG, 8 

invention. The memory free code generating unit 105 inserts illustrates processing performed by the memory free code 

a code for freeing memory immediately after the point at generating unit 105 on the program shown in FIG. 7, and 

which a lifetime ends, based on a lifetime output from the FIG. 9 illustrates processing performed by the memory free 

memory lifetime analyzing unit 104. When the source 65 code deleting unit 110 on the program shown in FIG. 8. Note 

program 1 is written in a language which includes an explicit that the following explanation uses a program written in 

instruction for dynamically freeing memory, the memory C++, but the invention may be applied in a similar way to 
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C, Java and the like. Numerical references (1) to (4) and the 
like in FIG. 6 denote signals specifying code. Codes unre- 
lated to variable A, variable B or their respective allocated 
memory areas may be inserted between code (1) and code 
(4) in FIG. 6 and between code (1) and code (5) in FIG. 7. 
Furthermore, program changes like the ones shown in FIGS. 
8 and 9 are actually performed on the intermediate format 
program 2, but corresponding source programs 1 written in 
C++ are shown here for ease of explanation. 

In FIG. 3, the source program decoder 101 in the program 
conversion apparatus 100 (see FIG. 2) first performs front- 
end processing in the same way as in a conventional 
program conversion apparatus, thereby converting the 
source program 1 into the intermediate format program 2 
(Sll). Following this, the memory allocation code detector 
102 detects, from the intermediate format program 2, codes 
having a specific format (i.e malloc in C. new in C++ and 
Java), that are used for dynamically allocating memory to 
variables, array variables, objects and the like (S12). Then, 
the memory reference code detector 103 performs reference 
code detecting processing for detecting reference codes to 
memory allocated by codes detected in the intermediate 
format program 2 at S12 (S13). 

DU (defined-use) information and UD (use -defined) 
information obtained by data-flow analysis are used in 
reference code detection. The technique of data-flow analy- 
sis is described in more detail in Compilers: Principles, 
Techniques, and Tools by Alfred V. Aho, Ravi Sethi and 
Jeffrey D. Ullman, pub. Addison-Wesley 1985. 

DU information and UD information are used to detect 
codes showing definitions and uses for variables and the like 
in an intermediate format program 2, but such information 
does not show definitions and uses for memory directly. In 
other words, when a variable is assigned to a dynamic 
memory address for a variable that has already been defined, 
there is a possibility that dynamic memory for the already 
defined variable may be referenced as memory for another 
variable. 

Here, the memory reference code detector 103 performs 
detection of reference codes that are assumed to belong to 
already allocated dynamic memory, including a code assign- 
ing a variable to a dynamic memory address for another 
variable, and code referencing memory for the new variable. 

The memory reference code detection processing per- 
formed by the memory reference code detector 103 is 
described in more detail with reference to FIGS. 4 to 7. 
Memory reference code detection processing finds a refer- 
ence code to a variable x and a code assigning an address at 
which a variable x is stored (the content of this processing 
is shown in FIG. 5). This processing is realized by using a 
recursive function seek_use__and 13 addresssubst(a). 

In the reference code detection processing of FIG. 4, a 
variable referencing allocated memory is defined as a 
(S131). Then a subroutine seek__use__and_addresssubst(a) 
is called. This subroutine is used to find a reference code for 
a and a point assigning the address of a (S132). The return 
value refplace_x for the subroutine seek_use_and_ 
addresssubst(a) is stored so as to include all reference codes 
showing memory for the variable a (S133). 

Furthermore, in the subroutine seek_use__and__ 
addresssubst(a) shown in FIG. 5, all the reference codes for 
the variable x are detected from DU information and UD 
information, and recorded in refplace_ - x (S1321). Following 
this, determination of whether an unprocessed code assign- 
ing an address to the variable x is still remaining is per- 
formed (S1322). 
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If an unprocessed code is still remaining (S1322: Yes), 
this code assigning an address to the variable x is detected 
as def_y (S1323). A variable y is defined by def_y, and 
seek_use_and_addresssubst(y) is executed (S1324). The 
return value forseek_use_and_addresssubst(y) is stored in 
refplace_x (S1325). 

If no unprocessed code remains (S1322: No), refplace_x 
is set as the return value (S1326) and the processing is 
completed. 

In the program of FIG. 6, memory dynamically allocated 
to a variable A by a code (1) is referenced by codes (2) and 
(3) stipulating uses of variable A. Code (3) defines a variable 
B by assigning the address of variable A to variable B. This 
definition references the memory for variable A. In a pro- 
gram like the one in FIG. 6, the memory reference code 
detector 103 performs reference code detection processing 
(FIG. 4), treating all of codes (1) to (4) as reference codes 
referring to a same memory area, and outputs data showing 
the reference codes to the memory lifetime analyzing unit 
104. 

When reference code detection processing (FIG. 3, S13) 
performed by the memory reference code detector 103 has 
been completed, lifetimes are analyzed by the memory 
lifetime analyzing unit 104 (FIG. 3, S14). 

Lifetime analysis is explained with reference to FIGS. 6 
and 7. 

In the program shown in FIG. 6, all of the codes (1) to (4) 
can be assumed to be reference codes for the same memory 
area, as a result of reference code detection processing 
performed by the memory reference point detector 103, The 
memory lifetime analyzing unit 104 receives input data 
showing these reference codes, treats an interval including 
lifetimes for variables A and B as the lifetime for the 
corresponding memory area, and outputs data showing the 
interval to the memory free code generating unit 105, the 
local memory determining unit 106, the loop defining 
memory determining unit 107, the loop denning local 
memory determining unit 108 and the loop memory deter- 
mining unit 109. 

Here, when the memory lifetime analyzing unit 104 uses 
a language like C or C++ which allows the programmer to 
write a code for freeing memory in the source program 1, the 
memory lifetime is defined as extending until the last code 
to be referenced, rather than extending as far as the memory 
free code. Allocated memory is classified as garbage by the 
program immediately following a point where the last code 
to be referenced is written, thus excluding the code for 
freeing memory. 

In other words, since the code (5) in the program shown 
in FIG. 7 for freeing variable A also refers to the memory 
area for variable A, the memory reference code detector 103 
detects this code as a reference code according to the DU 
and UD information. However, since code (5) is a code for 
freeing memory, the memory lifetime analyzing unit 104 
does not detect the point where code (5) is written as the end 
of the lifetime, instead determining the memory lifetime to 
be the interval extending from code (1) to code (4) (identical 
to the equivalent part of the program shown in FIG. 6). 

Once the memory lifetime analyzing unit 104 has com- 
pleted lifetime analyzing processing (FIG. 3, S14), the loop 
memory determining unit 109 determines whether the life- 
time of the allocated memory corresponding to the code 
detected in S12 is confined within one loop repetition, i.e. 
whether condition C is satisfied (S15). If the lifetime is 
confined within one loop repetition (S15: Yes), the memory 
share code generating unit 114 performs share processing 
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(SI 6) and processing moves to S24. The procedure for been performed on all dynamically allocated memory. If it 

performing share processing is described in more detail later has not been performed on all dynamically allocated 

in this specification with reference to the flowchart in FIG. memory (S25: No), the processing of S12 onwards is 

13 performed for the unprocessed memory, and when the above 

If the lifetime is not confined to one loop repetition (S15: 5 processing has been performed for all dynamically allocated 

No), the loop defining local memory determining unit 108 memory (S25: Yes), the executable program generating unit 

- y / . i i j i .i 115 performs back end processing in the same way as in a 

determines both whether the lifetime is loc<d and whether cony y cational program conversion apparatus, thereby con- 

the starting point of the interval is within a loop having a vertlQg tne intermediate format program 2 to an executable 

calculable number of repetitions, i.e. whether conditions A program 3 (S26). This completes the processing, 

and B are simultaneously satisfied (S17). If the lifetime is 10 ^ following explanation descr i bes in m0 re detail those 

local and within a loop having a calculable number of parts of me above-outlined processing performed by the 

repetitions (S17: Yes), the memory continuous localizing program conversion apparatus 100 that are particularly 

code generating unit 113 performs continuous localizing relevant to this invention. The localizing processing of S23, 

processing (explained later with reference to FIG. 12) (SIS) me continuous processing of S20, the continuous localizing 

and processing moves to S24. * 5 processing of S18, and the share processing of S16 are 

Note that the number of loop repetitions is normally explained with reference to FIGS. 10 to 13 respectively, 

determined by analyzing a conditional expression that is FIGS. 14 to 17 show programs changed by these processes, 

indicated together with the code describing the loop. In reality these changes take place within the intermediate 

However, it may be impossible to specify the number of loop format program 2, but for the sake of convenience, corre- 

repetitions if a loop indicates a comparison using an unpre- 20 sponding source programs 1 written in C++ are shown, 

dictable variable as its conditional expression. In this case, FIG. 10 is a flowchart showing in detail localizing pro- 

the number of loop repetitions is described as incalculable. cessing performed by the memory localizing code generat- 

If the lifetime does not satisfy both conditions A and B ing unit 111 in S23 of FIG. 3. 

(S17: No), the loop defining local memory determining unit The memory localizing code generating unit 111 (FIG. 2) 

108 determines whether it has a starting point within a loop changes the intermediate program 2 so that a memory area 

having a calculable number of repetitions, i.e. whether it determined to have a local lifetime, Le. to satisfy condition 

satisfies condition B (S19). If the fife time has a starting point A, by the local memory determining unit 106, is allocated to 

within such a loop (S19: Yes), the memory continuous code a local variable rather than being allocated dynamically, 

generating unit 112 performs continuous processing 3Q More specifically, in the localizing processing shown in 

(described later in the specification with reference to FIG. FIG. 10, a code (for example malloc in C, or new in C++ and 

11) (S20), the memory free code generating unit 105 inserts Java) for dynamically allocating a memory area m is deleted 

a code for freeing memory immediately following the end of (S231). Then a code for allocating a memory area 1 to a local 

the lifetime (S21), and processing then moves to S24. variable having the same size and shape as the variable that 

Specifically, processing is performed by the memory free 35 was allocated to memory area m is generated (S232). Next, 

code generating unit 105 on the program shown in FIG. 7. all codes referencing memory area m are changed to codes 

This means that a code (5) for freeing the variable A is referencing memory area 1 (S233), and the processing is for 

inserted in the program, in addition to an identical code (6) a plurality of loop repetitions. 

already written by the programmer. The resulting program Specifically, in the continuous processing shown in FIG. 

resembles the one shown in FIG. 8. 4Q n t a co d e dynamically allocating the memory area m is 

If the lifetime is not within a loop having a calculable deleted (S201) and a size s and number of loop repetitions 

number of repetitions (FIG. 3, S19: No), the loop defining k are detected for the allocated memory area m (S202, 

local memory determining unit 108 determines whether it is S203). Then the total size (sxk) of the area to be allocated 

local, i.e. satisfies condition A (S22). If the lifetime is local for the loop is calculated (S204). Next, a code for allocating 

(S22: Yes), the memory localizing code generating unit 111 45 a memory area aw having a size of (sxk) is inserted outside 

performs localizing processing (described later with refer- the loop, immediately prior to the start of the loop execution 

ence to FIG. 10) (S23), and processing moves to S24. If the (S205). All the codes referencing the memory area m are 

lifetime is not local (S22: No), a code for freeing memory is then changed to codes referencing the memory area aw 

inserted immediately following the lifetime, at S21, and (S206) and the processing is completed, 

processing moves to S24. 50 When the program is changed, the memory area to be 

At S24, a code generated in the intermediate format referenced is indicated by finding addresses add that should 

program 2 by the front end processing (Sll) that has already be newly referenced inside the memory area aw. This is 

been detected by the memory reference code detector 103, achieved by repeating the following formula for each of a 

is deleted by the memory free code deleting unit 110. This number of loop repetitions i (i=l, 2, 3 ... k): 

code corresponds to a code (free in C, delete in C++, and so 55 add=(a first address for memory area aw)+[sx(i-l)}. 

on), originally written in source program 1 by the FIG. 15 shows the change in the program caused by 

programmer, for freeing dynamic memory. Specifically, the continuous processing. FIG. 15A shows a program prior to 

memory free code deleting unit 110 performs processing on the performance of continuous processing, and FIG. 15B 

the program shown in FIG. 8, so that a code written by the shows a program following the performance of continuous 

programmer for freeing memory relating to variable A is $o processing. 

deleted, resulting in the program shown in FIG. 9. In other [n the program shown in FIG. 15 A, a code (1) dynami- 

words, a code like the one in FIG. 7, for freeing memory cally completed. 

relating to variable A that has not been freed even though its FIG. 14 shows program changes made by the localizing 
lifetime has ended, is moved to a position immediately processing. FIG. 14A shows a program prior to the perfor- 
following the lifetime for A, as shown in FIG. 9. 65 mance of localizing processing, and FIG. 14B shows a 
Following this, in S25 of FIG. 3, the program conversion program following the performance of localizing process- 
apparatus 100 determines whether the above processing has ing. 
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In the program shown in FIG. 14 A, memory is dynami- In the program shown in FIG. 16A, a code (1) dynami- 
cally allocated by a code (1), and the allocated memory is cally allocates memory within a for loop, and codes (2) to (4) 
referenced by each of codes (2) to (4), but since the lifetime each reference the allocated memory, but since the lifetime 
for this memory is local, it can be localized using the of the memory is local, and the starting point of the lifetime 
localizing processing shown in FIG. 10. s is within a loop having a calculable number of repetitions, 

In this processing, as shown in FIG. 14B, a code (1) that the continuous localizing processing of FIG. 12 is possible, 
was present in the program before localizing was performed Note that since the memory area referenced in this pro- 
is deleted, and a code (11) allocating memory to a local gram is not confined to one loop repetition, memory cannot 
variable is inserted instead. The memory allocated by code be shared (memory share processing is described later in the 
(11) is referenced by codes (12) to (14). 10 specification). In other words, in the program shown in FIG. 

FIG. 11 is a flowchart showing in detail the continuous 16A, the address of a memory area allocated by the code (1) 

processing performed by the memory continuous code gen- in a loop when i=4, is held as a variable b using a code (4), 

erating unit 112 in S20 of FIG. 3. and referenced by a code (2) in a next loop when i-5. 

The memory continuous code generating unit 112 (FIG. Specifically, in the continuous localizing processing 

2) changes the intermediate format program 2 so that a 15 shown in FIG. 16B, a code (1) which existed in the program 

memory area having a lifetime with a starting point deter- prior to continuous localizing is deleted, and a code (11) 

mined by the loop defining memory determining unit 107 to allocating memory to an array variable having a number of 

be within a loop having a calculable number of repetitions elements equal to the number of for loop repetitions is 

is allocated continuously allocates memory within a for inserted instead, prior to the start of the for loop. Here, each 

loop, codes (2) and (3) each reference the allocated memory, 20 element in the array variable is a local variable. Codes (12) 

and code (4) enables the address of an allocated memory to (14) each reference the memory allocated by code (11). 

area to be used as an argument when a function is called. FIG. 13 is a flowchart showing in detail share processing 

Since the program contains the code (4), the lifetime of the performed by the memory share code generating unit 114 in 

memory is not local, but the starting point of the lifetime is S16 of FIG. 3. 

within a loop having a calculable number of repetitions, so 25 The memory share code generating unit 114 (FIG. 2) 

the continuous processing in FIG. 11 can be performed. changes the intermediate format program 2 so that memory 

Specifically, continuous processing is performed as determined by the loop memory determining unit 109 to 

shown in FIG. 15B, so that a code (1) which existed in the have a lifetime confined to one loop repetition i.e to satisfy 

program prior to continuous is deleted, and a code (11) condition C, is shared. This means that, instead of the 

allocating memory to an array variable is instead inserted 30 memory being allocated dynamically, the same memory is 

prior to the start of the for loop. Codes (12) to (14) each used for a plurality of loop repetitions, 

reference the memory allocated by code (11). Memory having a lifetime confined to one loop repetition 

FIG. 12 is a flowchart showing in detail the continuous becomes * garbage* the next time the loop is repeated. Since 

localizing processing performed by the memory continuous there is no need to allocate variables dynamically to this kind 

localizing code generating unit 113 in S 18 of FIG, 3. 35 of memory, its lifetime is clearly local. This means that a 

Hie memory continuous localizing code generating unit memory area allocated to a local variable can be referenced 

113 (FIG. 2) changes the intermediate format program 2 so repeatedly by being overwritten on each loop repetition. As 

that a memory area determined by the loop defining local a result, the purpose of the original program can be attained 

memory determining unit 108 to have a local lifetime and without program execution that requires complicated pro- 

also to have a lifetime starting point that is within a loop 40 cessing. 

having a calculable number of repetitions, i.e. that simulta- Specifically, in the share processing shown in FIG. 13, a 

neously satisfies conditions A and B, is allocated to a local code for dynamically allocating the memory area m is 

array variable rather than being allocated dynamically. deleted (SI 61) and a size s and shape for the allocated 

Specifically, in the continuous localizing processing memory area m detected (S162). Next, a code for allocating 

shown in FIG. 12, a code dynamically allocating a memory 45 a local variable L having the same size and shape as a 

area m is deleted (S181) and a size s and number of loop variable that was allocated to the memory area m is gener- 

repetitions k are detected for the allocated memory area m ated within a function having a loop (SI 63). The codes 

(S182, SI 83). Next, a code for allocating a local array referencing the memory area m are all changed to codes 

variable L is inserted. The variable L has elements of the referencing the local variable L (S164) and the processing is 

same size and shape as the variable allocated to the memory 50 completed. 

area m, the number of elements being equal to the number FIG. 17 shows program changes performed by the share 

of loop repetitions k (S184). All the codes referencing the processing. FIG. 17 A shows a program prior to the perfor- 

memory area m are then changed to codes referencing the mance of share processing and FIG. 17B shows the program 

memory areas for the elements for the local array variable L following the performance of share processing. 

(S185), and the processing is completed. 55 In the program shown in FIG. 17A, a code (1) dynami- 

When the codes are changed, the memory to be referenced cally allocates memory within a for loop, and codes (2) and 

is indicated by finding an address add for the memory area (3) each reference the allocated memory, but since the 

corresponding to each element in the array variable L. This lifetime of the memory is confined to one loop repetition, the 

is achieved by repeating the following formula for each of share processing shown in FIG. 13 may be performed, 

a number of loop repetitions i (i=l, 2, 3 ... k): 60 Specifically, in the share processing illustrated in FIG. 

addc^a first address of the memory +[sx(i-l)}. for array 17B, a code (1) that existed in the original program is 

variable L) deleted, and a code (11) for allocating a local variable is 

FIG. 16 shows program changes caused by the continuous instead inserted at a designated position in a function having 

localizing processing. FIG. 16 A shows a program prior to a for loop. Codes (12) and (13) reference the memory 

the performance of continuous localizing processing, and 65 allocated by code (11). 

FIG. 16B shows the program following the performance of To summarize, in the program conversion apparatus 100, 

continuous localizing processing. the localizing processing of FIG. 10, the continuous pro- 



09/09/2004, EAST Version: 1.4.1 



US 6,647,547 Bl 



IS 



16 



cessing of FIG. 11, the continuous localizing processing of 
FIG. 12, and the share processing of FIG. 13 are performed 
on memory indicated as being dynamically allocated by the 
program in the original source program 1, according to the 
lifetime of the allocated memory. Processing for localizing 
memory that has been dynamically allocated is performed in 
all of these processes, except for continuous processing, and 
the subsequent processing shown in, for example, FIG. 3, 
S21, and S24. Following continuous processing, processing 
for freeing dynamically allocated memory immediately fol- 
lowing the end of its lifetime is performed. Any memory 
having a lifetime that is not the object of the above- 
mentioned four processes is also freed immediately follow- 
ing the end of its lifetime. 

This means that the program conversion apparatus 100 
changes the source program 1 so that memory indicated as 
being dynamically allocated is instead allocated statically 
rather than dynamically. A shortening of the interval 
between allocation and freeing is also assured, and the 
burden of dynamic memory management borne by the 
execution thread when the program is executed is reduced. 

In addition, in the continuous processing, dynamic 
memory is continuously allocated at one time, thereby 
increasing the efficiency of the recycling processing per- 
formed by the execution thread, and making it unnecessary 
to repeat memory allocation processing numerous times 
within a loop. This enables program execution to be per- 
formed at high speed. 

Since the source program for the above program conver- 
sion apparatus 100 is assumed to be written in C++, the 
instruction for freeing dynamically allocated memory needs 
to be explicitly indicated by the program. However, the 
invention may be applied to a program conversion apparatus 
for a language like Java that does not use this kind of 
instruction. This is achieved by using the invention without 
the processing relating to free instructions that correspond to 
code in the source program 1, such as processing performed 
by the memory free code generating unit 110 (FIG. 2). 

Furthermore, the program conversion apparatus 100 only 
performs compiling from the source program to the execut- 
able program, and the executable program is assumed to be 
executed by another device, but the executable program may 
also be executed by the program conversion apparatus. 

In the program conversion apparatus 100, instructions in 
the executable program are assumed to be generated for 
direct interpretation by the CPU, with each instruction 
relating to a code for freeing memory in the source program 
1. However, a library subroutine (function) for calling an 
OS, a virtual machine or similar, and an instruction for 
calling such a library subroutine can be generated in the 
executable program for each instruction relating to a code 
for freeing memory in the source program 1. Note that 
platforms which do not include a direct instruction for 
freeing dynamic memory can indicate freeing of dynamic 
memory by using a library subroutine. The program con- 
version apparatus 150 described below performs just such a 
function. 

The following is an explanation of a modification of the 
program conversion apparatus 100, the program conversion 
apparatus 150. 

FIG. 18 is a block diagram showing an overall construc- 
tion for the program conversion apparatus 150. Those com- 
ponents having the same function as components in the 
program conversion apparatus 100 are given the same 
numerical references. Furthermore, the procedure for the 
processing performed by each of these components con- 
forms to that described in FIG. 3. 
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The program conversion apparatus 150 has a memory free 
call code generating unit 151 and a memory free library 
subroutine 152 instead of the memory free code generating 
unit 105 of the program conversion apparatus 100. 

The memory free call code generating unit 151 receives 
input data showing memory lifetimes output from the 
memory free code generating unit 105 and the memory 
lifetime analyzing unit 104, and inserts a code for calling a 
library subroutine used to free memory immediately follow- 
ing the end of the memory lifetime. This adds the memory 
free library subroutine 152, in which this code is written, to 
the intermediate format program 2. 

A program conversion apparatus such as 150 which uses 
a library subroutine to free dynamic memory functions 
changes memory indicated as being dynamically allocated 
by an original program to statically allocated memory in a 
similar way to the program conversion apparatus 100. This 
enables the interval between allocation and freeing to be 
shortened, and reduces the memory management burden 
placed on the execution thread when program execution is 
performed. 

Although the present invention has been fully described 
by way of examples with reference to accompanying 
drawings, it is to be noted that various changes and modi- 
fications will be apparent to those skilled in the art. 
Therefore, unless such changes and modifications depart 
from the scope of the present invention, they should be 
construed as being included therein. 

What is claimed is: 

1. A program conversion apparatus for converting a 
source program to an executable program, the source pro- 
gram including a first descriptor indicating dynamic memory 
allocation, and a second descriptor indicating memory allo- 
cation only when instructions are executed within a specified 
block, the program conversion apparatus comprising: 

a specifying means for specifying a lifetime of allocated 
memory by referring to positions in the source program 
of (1) the first descriptor and (2) reference descriptors 
indicating references to memory allocated by the first 
descriptor; 

a determining means for determining whether the speci- 
fied lifetime is confined within the specified block; and 

a generating means for generating an instruction in an 
executable program when the specified lifetime is 
determined to be confined within the specified block, so 
that memory indicated as being allocated by the first 
descriptor in the source program is indicated as being 
allocated by the second descriptor. 

2. A program conversion apparatus for converting a 
source program to an executable program, the source pro- 
gram including a first descriptor indicating dynamic memory 
allocation for a specified object, a second descriptor indi- 
cating (1) repetition of instructions within a specified block 
and (2) a number of repetitions, and a third descriptor 
indicating continuous dynamic memory allocation for a 
specified plurality of objects, the program conversion appa- 
ratus comprising: 

a specifying means for specifying a position of the first 
descriptor in a source program; 

a determining means for determining whether the speci- 
fied position of the first descriptor is within the speci- 
fied block; 

a detecting means for detecting the number of repetitions 
shown by the second descriptor corresponding to the 
specified block; and 

a generating means for generating an instruction in an 
executable program when the specified position of the 
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first descriptor is determined to be within the specified 
block, so that memory, determined by repeating the 
memory allocation indicated by the first descriptor for 
the number of repetitions shown by the second 
descriptor, is indicated as being allocated by the third 
descriptor, the third descriptor being positioned outside 
the specified block. 

3. A program conversion apparatus for converting a 
source program to an executable program, the source pro- 
gram including a first descriptor indicating dynamic memory 
allocation for a specified object, a second descriptor indi- 
cating (1) repetition of instructions within a specified small 
block, and (2) a number of repetitions, and a third descriptor 
indicating continuous memory allocation for a specified 
plurality of objects only when instructions are executed 
within a specified large block that includes the specified 
small block, the program conversion apparatus comprising: 

a specifying means for specifying a lifetime of allocated 
memory, by referring to positions in the source program 
of (i) the first descriptor and (ii) reference descriptors 
indicating references to memory allocated by the first 
descriptor; 

a determining means for determining whether the speci- 
fied lifetime is confined within the specified large block 
and also whether the position of the first descriptor is 
within the specified small block; 

a detecting means for detecting the number of repetitions 
shown by the second descriptor corresponding to the 
specified small block; and 

a generating means for generating an instruction in the 
executable program when (a) the specified lifetime is 
determined to be confined within the specified large 
block and (b) the position of the first descriptor is 
determined to be within the specified small block, so 
that memory, determined by repeating the memory 
allocation indicated by the first descriptor for the num- 
ber of repetitions shown by the second descriptor, is 
indicated as being allocated by the third descriptor, the 
third descriptor being positioned within the specified 
large block but outside the specified small block. 

4. A program conversion apparatus for converting a 
source program to an executable program, the source pro- 
gram including a first descriptor indicating dynamic memory 
allocation, a second descriptor indicating repetition of 
instructions within a specified small block, and a third 
descriptor indicating memory allocation only when instruc- 
tions are executed within a specified large block that 
includes the specified small block, the program conversion 
apparatus comprising: 

a specifying means for specifying a lifetime of allocated 
memory, by referring to positions in the source program 
of (1) the first descriptor and (2) reference descriptors 
indicating references to memory allocated by the first 
descriptor; 

a determining means for determining whether the speci- 
fied lifetime lasts for one execution duration of the 
specified small block; and 

a generating means for generating an instruction for the 
executable program when the specified lifetime is 
determined to last for less than one execution duration 
of the specified small block, so that memory indicated 
as being allocated by the first descriptor in the source 
program is indicated as being allocated by the third 
descriptor, the third descriptor being positioned within 
the specified large block but outside the specified small 
block. 
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5. A program conversion apparatus for converting a 
source program to an executable program, the source pro- 
gram including a first descriptor mdicating dynamic memory 
allocation, a second descriptor indicating that allocated 
memory is to be freed, and a third descriptor indicating 
memory allocation only when instructions are executed 
within a specified block, the program conversion apparatus 
comprising: 

a specifying means for specifying a lifetime of allocated 
memory by referring to positions in the source program 
of (1) the first descriptor and (2) reference descriptors 
indicating references to memory allocated by the first 
descriptor; 

a determining means for determining whether the speci- 
fied lifetime is confined within the specified block; and 

a generating means for generating an instruction in an 
executable program when the specified lifetime is 
determined to be confined within the specified block, so 
that memory indicated in the source program as being 

(a) allocated by the first descriptor and (b) freed by the 
second descriptor is indicated as being allocated by the 
third descriptor. 

6. A program conversion apparatus for converting a 
source program to an executable program, the source pro- 
gram including a first descriptor indicating dynamic memory 
allocation for a specified object, a second descriptor indi- 
cating that allocated memory is to be freed, a third descriptor 
indicating (1) repetition of instructions within a specified 
small block, and (2) a number of repetitions, and a fourth 
descriptor indicating memory allocation for a specified 
plurality of objects only when instructions are executed 
within a specified large block that includes the specified 
small block, the program conversion apparatus comprising: 

a specifying means for specifying a lifetime of allocated 
memory, by referring to positions in the source program 
of (A) the first descriptor and (B) reference descriptors 
indicating references to memory allocated by the first 
descriptor; 

a determining means for determining whether the speci- 
fied lifetime is confined within the specified large block 
and whether the position of the first descriptor is within 
the specified small block; 

a delecting means for detecting the number of repetitions 
for the third descriptor corresponding to the specified 
smaU block; and 

a generating means for generating an instruction in the 
executable program when (i) the specified lifetime is 
determined to be confined within the specified large 
block and (ii) the position of the first descriptor is 
determined to be within the specified small block, so 
that memory, determined by repeating the allocation of 
memory that is (a) allocated by the first descriptor and 

(b) freed by the second descriptor, for the number of 
repetitions shown by the third descriptor, is indicated as 
being allocated by the fourth descriptor, the fourth 
descriptor being positioned within the specified large 
block but outside the specified small block 

7. A program conversion apparatus for converting a 
source program to an executable program, the source pro- 
gram including a first descriptor indicating dynamic memory 
allocation, a second descriptor indicating that allocated 
memory is to be freed, a third descriptor indicating repetition 
of instructions within a specified small block, and a fourth 
descriptor indicating memory allocation only when instruc- 
tions are executed within a specified large block that 
includes the specified small block, the program conversion 
apparatus comprising: 
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a specifying means for specifying a lifetime of allocated 
memory by referring to positions in the source program 
of (1) the first descriptor and (2) reference descriptors 
indicating references to memory allocated by the first 
descriptor; 

a determining means for determining whether the speci- 
fied lifetime lasts for at least one execution duration of 
the specified small block; and 

a generating means for generating an instruction for the 
executable program when the specified lifetime is 
determined to last for less than one execution duration 
of the specified small block, so that memory indicated 
in the source program as being (a) allocated by the first 
descriptor and (b) freed by the second descriptor, is 
indicated as being allocated by the fourth descriptor, 
the fourth descriptor being positioned within the speci- 
fied large block but outside the specified small block. 

8. A program conversion method for converting a source 
program to an executable program, the source program 
including a first descriptor indicating dynamic memory 
allocation, and a second descriptor indicating memory allo- 
cation only when instructions are executed within a specified 
block, the program conversion method comprising: 

a specifying step for specifying a lifetime of allocated 
memory by referring to positions in the source program 
of (1) the first descriptor and (2) reference descriptors 
' indicating references to memory allocated by the first 
descriptor; 

a determining step for determining whether the specified 
lifetime is confined within the specified block; and 

a generating step for generating an instruction in an 
executable program when the specified lifetime is 
determined to be confined within the specified block, so 
that memory indicated as being allocated by the first 
descriptor in the source program is indicated as being 
allocated by the second descriptor. 

9. A program conversion method for converting a source 
program to an executable program, the source program 
including a first descriptor indicating dynamic memory 
allocation for a specified object, a second descriptor indi- 
cating (1) repetition of instructions within a specified block 
and (2) a number of repetitions, and a third descriptor 
indicating continuous dynamic memory allocation for a 
specified plurality of objects, the program conversion 
method comprising: 

a specifying step for specifying a position of the first 

descriptor in a source program; 
a determining step for determining whether the specified 

position of the first descriptor is within the specified 

block; 

a detecting step for detecting the number of repetitions 
shown by the second descriptor corresponding to the 
specified block; and 

a generating step for generating an instruction in an 
executable program when the specified position of the 
first descriptor is determined to be within the specified 
block, so that memory, determined by repeating the 
memory allocation indicated by the first descriptor for 
the number of repetitions shown by the second 
descriptor, is indicated as being allocated by the third 
descriptor, the third descriptor being positioned outside 
the specified block. 

10. A program conversion method for converting a source 
program to an executable program, the source program 
including a first descriptor indicating dynamic memory 
allocation for a specified object, a second descriptor indi- 
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eating (1) repetition of instructions within a specified small 
block, and (2) a number of repetitions, and a third descriptor 
indicating continuous memory allocation for a specified 
plurality of objects only when instructions are executed 
5 within a specified large block that includes the specified 
small block, the program conversion method comprising: 
a specifying step for specifying a lifetime of allocated 
memory, by referring to positions in the source program 
of (i) the first descriptor and (ii) reference descriptors 
10 indicating references to memory allocated by the first 
descriptor; 

a determining step for determining whether the specified 
lifetime is confined within the specified large block and 
also whether the position of the first descriptor is within 
the specified small block; 
a detecting step for detecting the number of repetitions 
shown by the second descriptor corresponding to the 
specified small block; and 
a generating step for generating an instruction in the 
2Q executable program when (a) the specified lifetime is 
determined to be confined within the specified large 
block and (b) the position of the first descriptor is 
determined to be within the specified small block, so 
that memory, determined by repeating the memory 
allocation indicated by the first descriptor for the num- 
ber of repetitions shown by the second descriptor, is 
indicated as being allocated by the third descriptor, the 
third descriptor being positioned within the specified 
large block but outside the specified small block. 
30 11. A program conversion method for converting a source 
program to an executable program, the source program 
including a first descriptor indicating dynamic memory 
allocation, a second descriptor indicating repetition of 
instructions within a specified small block, and a third 
35 descriptor indicating memory allocation only when instruc- 
tions are executed within a specified large block that 
includes the specified small block, the program conversion 
method comprising: 

a specifying step for specifying a lifetime of allocated 
40 memory, by referring to positions in the source program 
of (1) the first descriptor and (2) reference descriptors 
indicating references to memory allocated by the first 
descriptor; 

a determining step for determining whether the specified 
45 lifetime lasts for one execution duration of the specified 
small block; and 
a generating step for generating an instruction for the 
executable program when the specified fife time is 
determined to last for less than one execution duration 
50 of the specified small block, so that memory indicated, 
as being allocated by the first descriptor in the source 
program is indicated as being allocated by the third 
descriptor, the third descriptor being positioned within 
the specified large block but outside the specified small 
55 block. 

12. A computer- read able recording medium recording a 
program used by a program conversion apparatus to convert 
a source program to an executable program, the source 
program including a first descriptor indicating dynamic 
60 memory allocation, and a second descriptor indicating 
memory allocation only when instructions are executed 
within a specified block, the recorded program comprising: 
a specifying step for specifying a lifetime of allocated 
memory by referring to positions in the source program 
65 of (1) the first descriptor and (2) reference descriptors 
indicating references to memory allocated by the first 
descriptor; 
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a determining step for determining whether the specified 

lifetime is confined within the specified block; and 
a generating step for generating an instruction in an 
executable program when the specified lifetime is 
determined to be confined within the specified block, so 
that memory indicated as being allocated by the first 
descriptor in the source program is indicated as being 
allocated by the second descriptor. 
13. A computer-readable recording medium recording a 
program used by a program conversion apparatus to convert 
a source program to an executable program, the source 
program including a first descriptor indicating dynamic 
memory allocation for a specified object, a second descriptor 
indicating (1) repetition of instructions within a specified 
block and (2) a number of repetitions, and a third descriptor 
indicating continuous dynamic memory allocation for a 
specified plurality of objects, the recorded program com- 
prising: 

a specifying step for specifying a position of the first 

descriptor in a source program; 
a determining step for determining whether the specified 

position of the first descriptor is within the specified 

block; 

a detecting step for detecting the number of repetitions 
shown by the second descriptor corresponding to the 
specified block; and 

a generating step for generating an instruction in an 
executable program when the specified position of the 
first descriptor is determined to be-within the specified 
block, so that memory, determined by repeating the 
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a determining step for determining whether the specified 
lifetime is confined within the specified large block and 
also whether the position of the first descriptor is within 
the specified small block; 
a detecting step for detecting the number of repetitions 
shown by the second descriptor corresponding to the 
specified small block; and 
a generating step for generating an instruction in the 
executable program when (a) the specified lifetime is 
determined to be confined within the specified large 
block and (b) the position of the first descriptor is 
determined to be within the specified small block, so 
that memory, determined by repeating the memory 
allocation indicated by the first descriptor for the num- 
ber of repetitions shown by the second descriptor, is 
indicated as being allocated by the third descriptor, the 
third descriptor being positioned within the specified 
large block but outside the specified small block. 
15. A computer-readable recording medium recording a 
program used by a program conversion apparatus to convert 
a source program to an executable program, the source 
program including a first descriptor indicating dynamic 
memory allocation, a second descriptor indicating repetition 
of instructions within a specified small block, and a third 
descriptor indicating memory allocation only when instruc- 
tions are executed within a specified large block that 
includes the specified small block, the recorded program 



memory allocation indicated by the first descriptor for 30 comprising. 



the number of repetitions shown by the second 
descriptor, is indicated as being allocated by the third 
descriptor, the third descriptor being positioned outside 
the specified block. 
14. A computer-readable recording medium recording a 35 
program used by a program conversion apparatus to convert 
a source program to an executable program, the source 
program including a first descriptor indicating dynamic 
memory allocation for a specified object, a second descriptor 
indicating (1) repetition of instructions within a specified 40 
small block, and (2) a number of repetitions, and a third 
descriptor indicating continuous memory allocation for a 
specified plurality of objects only when instructions are 
executed within a specified large block that includes the 
specified small block, the recorded program comprising: 45 
a specifying step for specifying a lifetime of allocated 
memory, by referring to positions in the source program . 
of (i) the first descriptor and (ii) reference descriptors 
indicating references to memory allocated by the first 
descriptor; 



a specifying step for specifying a lifetime of allocated 
memory, by referring to positions in the source program 
of (1) the first descriptor and (2) reference descriptors 
indicating references to memory allocated by the first 
descriptor; 

a determining step for determining whether the specified 
lifetime lasts for one execution duration of the specified 
small block; and 

a generating step for generating an instruction for the 
executable program when the specified lifetime is 
determined to last for less than one execution duration 
of the specified small block, so that memory indicated 
as being allocated by the first descriptor in the source 
program is indicated as being allocated by the third 
descriptor, the third descriptor being positioned within 
the specified large block but outside the specified small 
block. 
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